Current models for network/service authentication and authorization are often based on a three-entity model comprising: a client, being the entity one wishes to authenticate, in some contexts also referred to as “peer” or “supplicant”; an authenticator, capable of taking a decision whether to accept an authentication and authorize resource usage, and a back-end authentication server, maintaining credentials and other authentication-essential information related to the client. Sometimes, the authenticator and authentication server may be co-located. However, in a network serving a large number of clients, it will often be preferable to have one or more separate back-end authentication servers, rather than an architecture which has to handle the client's individual requests at the network access points, or attachment points. By way of example, in the latter example, implementation of specifics of an applied authentication method can be placed in the back-end authentication servers, and in the client, only, thereby obtaining a higher level of flexibility and security, while reducing the amount of functionality in the serving network, e.g. in the authenticator. In such situations, the authenticator is sometimes referred to as an “AAA client”, not to be confused with the client being authenticated (as previously mentioned also referred to as supplicant or peer). Most of the back-end authentication servers used today provides a complete range of functions with respect to Authentication, Authorization and Accounting (AAA) within a single server. Concrete examples of servers providing the mentioned functionality include Home Location Register and Authentication Centers (HLR/AuC), used in 2G/3G networks; Home Subscriber Servers (HSS), used in 4G networks, supporting 2G/3G/4G Authentication and Key Agreement (AKA) protocols, as well as general purpose AAA servers, supporting the Extensible Authentication Protocol (EAP), or any other authentication protocol. It should be noted though that in current 2G/3G/4G networks, the predominant way to authenticate clients, comprised in communication devices, is through the use of Subscriber Identity Module/Universal Subscriber Identity Module (SIM/USIM) applications on Universal Integrated Circuit Card (UICC). While the database functionality is placed in the HLR/AuC or HSS back-end, the serving network (VLR/MSC, SGSN or MME) is nevertheless not transparent to all details of the authentication protocol. In EAP-based architectures, however, the serving network may often be made fully transparent also to such details.
For each access request, an authentication server needs to keep a state alive for the duration of an authentication period. This is necessary in order to ensure a sufficient level of security, e.g. for being able to withstand impersonation attempts and replay attacks, but it may also be necessary from a purely administrative point of view, e.g. for being able to map received responses to an earlier issued request message. The authentication server therefore needs to maintain the state during the complete protocol execution of the authentication procedure for a given client. By way of example, in a challenge response authentication protocol, the server sends a random challenge to the client. When the response to this challenge is received by the authentication server, the authentication server needs to verify that the response corresponds to the sent challenge. In order to be able to do that, the authentication server generally needs to store the challenge while waiting for the response.
In a typical 4G setting the authenticator, keeping the state during the authentication protocol execution, is the Mobility Management Entity (MME), while in a 5G or other setting one can instead envision that authentication will be performed, using the EAP. Reasons for this could for example be the additional flexibility and simplicity offered by allowing plural different authentication methods, while centralizing dependency on authentication specific details to a smaller number of backend servers. In the latter case, the entity maintaining state would no longer be the MME, but rather the HSS, or the 3rd generation Partnership Project (3GPP) AAA server. The latter is presently used as the authentication server for enabling non-3GPP access to the Evolved Packet Core (EPC).
In a network, such as e.g. a 5G network, comprising a large number of peers, the number of authentication protocols simultaneously running on a given server, and hence, the number of states which the server need to keep, can grow prohibitively large.
Indeed, the scalability is a relevant problem not only for network authentication, but also for authentication related to other forms of service requests. Thus, in general, the requested service could be the connectivity/network access itself, but it could also be some higher layer application service, such as e.g. voice calls, IP multimedia communication services, access to a content, or gaming services, or, the like. Thus, the posed problem is applicable not only to more “pure” network access authentication scenarios, but also to application or service layer authentication, using e.g. ISIM, certificates, passwords, various security tokens, etc. In all of these situations, large scale systems may imply large state-storage requirements on the authentication server.